Merge branch release-ios-v3.3.5 into master #6884
Conversation
Fixes the issue where our stripped dynamic build did not have a valid dSYM. Disabling GCC_GENERATE_DEBUGGING_SYMBOLS for SYMBOLS=NO builds meant that those builds had no debug symbols to strip or add to a dSYM.
Upload any events collected when the app was in use for apps that only have "when in use" location permissions. Also, for all apps, avoid posting event data if there is only a single event.
Our release builds for device (with lipoed simulator binary) create a dSYM files for both the device and simulator. However the script only copied the device dSYM file to the output location. This adds a step to lipo together both the device and simulator dSYM files. Mapbox.framework.dSYM now holds armv7 and arm64 slices.
|
@friedbunny, thanks for your PR! By analyzing the history of the files in this pull request, we identified @boundsj, @1ec5 and @bleege to be potential reviewers. |
On the command line, perform a (non-FF) merge and resolve conflicts by accepting whatever's already on master. |
This PR is the result of doing that — a |
|
Then you can non-FF merge this PR branch into master. |
|
Thanks @1ec5 and @jfirebaugh. If we do another non-FF merge into master, I believe there will be two consecutive merge commits: |
|
No, fast-forward |
|
🙇 |
This merges the
release-ios-v3.3.5branch back to master. That branch was created by going back to theios-v3.3.4tag and then cherry-picking in the necessary commits.Most of the commits included in this PR already exist in master. The ones that do not yet are:
release-ios-v3.4.0)Is this the correct way to go about reconciling this release branch with master? My understanding is that this PR adds several (apparently) duplicate commits, but those are likely necessary if anyone were to want to check out the
ios-v3.3.5tag and try to compile it again./cc @jfirebaugh @boundsj @1ec5